[CI] Reduce the ITCase coverage in Flink to avoid 60min timeout - #3692

similar to #3273.

similar to #3273.

@luoyuxia Thanks for pointing out. I made some change based on the suggestions from your issue.

Reduce the ITCase coverage on the backward-compatibility Flink versions (1.18 and 1.19) to a 6-test smoke subset that covers the essential read/write paths. The full test suite continues to run on the representative version (fluss-flink-common, aligned to Flink 1.20 and 2.2).

Kept (smoke) vs. skipped

@Guosmilesmile This PR is very useful, but seems the flink/spark3/spark3-scala213 still last about nearly 1 hour, i guess we need to optimize them too.

Flink Common run in 1.20 version, we also run 1.20 in full test-coverage. So reduce the ITCase coverage for 1.20 align with 1.18 and 1.19 reduce cost time for flink module.

Regarding the Spark part, I would prefer to address it in the next PR. Let's focus on handling the Flink part for now.

Regarding the Spark part, I would prefer to address it in the next PR. Let's focus on handling the Flink part for now.

Thanks, that makes sense. If you don't have the bandwidth, I'd be happy to take it and open a spark related PR. Would that be okay with you?

Thanks, that makes sense. If you don't have the bandwidth, I'd be happy to take it and open a spark related PR. Would that be okay with you?

Sure, go ahead. That'd be great, thanks!

cc @loserwang1024

Rebase main.

Thanks for working on this and for helping reduce the Flink CI time.

After comparing this approach with #3913, my main concern is that this PR hard-codes four ITCase classes in the version-specific POM files. This requires maintainers to update the corresponding allowlists whenever a new compatibility-sensitive test is added. If a POM update is missed, the new test may be silently excluded from older Flink versions.

#3913 addresses the same CI cost with a more fine-grained multi-version testing mechanism. Flink 1.20 remains the full regression baseline, while Flink 1.18, 1.19, and 2.2 run only tests explicitly marked with @MultiVersionTest. The marker can be applied at either method or class level, covers both ITCases and unit tests, and avoids starting test classes that contain no selected tests. This reduces repeated test execution while keeping compatibility coverage explicit and close to the tests themselves, without maintaining class-name allowlists across multiple POM files.

Since #3913 supersedes this approach and should be easier to maintain and extend, I’m going to close this PR.

Thank you again for identifying the CI performance problem and contributing a solution. This work helped move the multi-version test optimization forward.